With the advent of the computer age, computer and software users have grown accustomed to user-friendly software applications that help then write, calculate, organize, prepare presentations, send and receive electronic mail, make music, and the like. For example, modern electronic word processing applications allow users to prepare a variety of useful documents. Modern spreadsheet applications allow users to enter, manipulate, and organize data. Modern electronic slide presentation applications allow users to create a variety of slide presentations containing text, pictures, data or other useful objects.
Many such applications operate according to component frameworks where a number of application components run sequentially and/or concurrently for executing individual methods of a given overall application method. Typically, concurrent component methods require multi-threading of various methods. That is, an application that supports concurrent operations uses multiple method threads. A fundamental requirement of such an application is its ability to synchronize the multiple threads so that any data that is shared among the threads is consistent. An area of difficulty in software is reentrancy. A problem introduced often by synchronization methods is non-deterministic reentrancy. Generally, reentrancy occurs when a thread makes a nested call and thereby enters the same object a second time before completing the first call. For example, if a thread is executing a call to a first task of a first object and, as part of that execution, calls a task of a second object, then the thread enters the second object before completing and returning from the call to the first object. If part of the execution of the task of the second object includes calling a second task of the first object, then the thread reenters the first object before completing and returning from the original call to the first object.
Synchronization of application components and multi-threading of application methods are complex problems. For example, it can be difficult to coordinate execution of various threads, especially when instructions in two threads need to use the same data or resources. An instruction on a first thread might change data that is needed by an instruction on a second thread. If that data is changed before the instruction on the second thread is executed, it can cause an error in the execution of the program. For conventional applications requiring component synchronization and multi-threading, a variety of prior threading models have been employed including Java-style synchronized methods and statements, common language runtime (CLR), synchronization contexts, apartment threading and rental threading. Use of such models requires inclusion of complex logic in an application's programming for properly handling multiple method threads. Using these models with a conventional application, concurrency must be designed into specific parts of the application and must be tested for correctness against deadlock and race conditions.
Such prior models do not work well, if at all, with dynamically composed application frameworks where an application is made up of a number of components that are dynamically generated or reconfigured based on data received by those components or by other related components of the application. This is problematic because such prior methods force multi-threaded systems to be compartmentalized into specific areas of the application. For such dynamically generated and reconfigured applications, it is necessary that application components be written without complex thread-handling logic, as associated with prior threading models.
It is with respect to these and other considerations that the present invention has been made.